गिट आज सबसे व्यापक रूप से उपयोग किया जाने वाला संस्करण नियंत्रण प्रणाली है, और यह सुनिश्चित करने के लिए कि आप कभी भी प्रतिबद्ध परिवर्तन नहीं खोते हैं, यह विभिन्न तरीकों से परिवर्तनों का ट्रैक रखता है। इसके अलावा, यह आपको विकास कार्यप्रवाहों पर जो नियंत्रण देता है उसका अर्थ है कि आप यह निर्धारित कर सकते हैं कि आपकी परियोजना का इतिहास कैसा दिखता है। गिट के पास इसके साथ मदद करने के लिए प्रतिबद्ध इतिहास को फिर से लिखने के लिए कई तंत्र हैं, जिनमें git commit --amend
, git rebase
, और git reflog
शामिल हैं।
इस लेख में, आप सीखेंगे कि अपने गिट प्रतिबद्ध इतिहास को फिर से व्यवस्थित करने और फिर से लिखने के लिए git reflog
का उपयोग कैसे करें, जबकि प्रतिबद्ध इतिहास को फिर से लिखने वाले जोखिम को कम करते हुए अक्सर।
गिट शाखाओं की युक्तियों में संशोधनों का ट्रैक रखने के लिए संदर्भ लॉग , या बस " रीफ्लॉग " नामक एक प्रणाली का उपयोग करता है। एक संदर्भ, जिसे अक्सर " रेफरी " के रूप में जाना जाता है, एक प्रतिबद्ध या शाखा के लिए एक संकेतक है जिसे कई गिट कमांड पैरामीटर के रूप में स्वीकार करते हैं। git checkout
, git reset
, और git merge
कुछ सामान्य git कमांड के उदाहरण हैं जो refs को पैरामीटर के रूप में स्वीकार करते हैं।
डिफ़ॉल्ट रूप से, reflogs पिछले 90 दिनों में प्रत्येक HEAD
स्थिति का ट्रैक रखता है। इसके अलावा, रीफ्लॉग इतिहास भंडार के लिए विशिष्ट है और दूरस्थ रूप से सुलभ नहीं है। शाखा टिप रीफ्लॉग के अलावा, गिट स्टैश के लिए एक अलग रीफ्लॉग है।
Reflogs को स्थानीय रिपॉजिटरी की .git
निर्देशिका के अंतर्गत विशिष्ट निर्देशिकाओं में संग्रहीत किया जाता है। ये git reflog
निर्देशिका .git/logs/refs/heads/.
, .git/logs/HEAD
, और साथ ही .git/logs/refs/stash
अगर git stash
का उपयोग रिपॉजिटरी पर किया गया है।
मूल रीफ्लॉग कमांड इस प्रकार हैं:
# To see activity on HEAD git reflog show
उपरोक्त कमांड का आउटपुट निम्न के जैसा दिखता है:
0a2e358 HEAD@{0}: reset: moving to HEAD~2 0254ea7 HEAD@{1}: checkout: moving from 2.2 to main c10f740 HEAD@{2}: checkout: moving from main to 2.2
अन्य सामान्य उपयोग इस प्रकार हैं:
# To see activity on HEAD, including timestamp git reflog show --date=relative #or git reflog --relative-date # same, on some_branch git reflog show --date=relative some_branch
डिफ़ॉल्ट रूप से, git reflog
HEAD
ref के reflog को आउटपुट करता है। प्रतीक HEAD
वर्तमान में सक्रिय शाखा को दर्शाता है। अन्य रेफरी के लिए रिफ्लॉग भी उपलब्ध हैं। git ref को एक्सेस करने के लिए इस्तेमाल किया जाने वाला सिंटैक्स name@{qualifier}
है, उदाहरण के लिए - otherbranch@{0}
। HEAD
रेफरी के अलावा, अन्य शाखाओं, टैग, रिमोट और गिट स्टैश को भी संदर्भित किया जा सकता है।
सभी रेफरी का पूरा रीफ्लॉग देखने के लिए, आप निष्पादित कर सकते हैं:
git reflog show --all
ऑर्डर किए गए इंडेक्स के अलावा, प्रत्येक रीफ्लॉग प्रविष्टि में एक टाइमस्टैम्प जुड़ा होता है जिसे गिट रेफ पॉइंटर सिंटैक्स के लिए क्वालीफायर टोकन के रूप में भी लीवरेज किया जा सकता है। यही वह है जो समय के साथ इन रीफ्लॉग प्रविष्टियों को फ़िल्टर करने में सक्षम बनाता है। आमतौर पर इस्तेमाल किए जाने वाले टाइम क्वालिफायर के उदाहरणों में शामिल हैं:
@{0}
@{6.minutes.ago}
@{2.hour.ago}
@{3.day.ago}
@{5.weeks.ago}
@{8.years.ago}
@{today}
@{2022-01-23.08:30:00}
@{1.day.10.hours.ago}
इन टाइम क्वालिफायर को जोड़ा जा सकता है (जैसे 1.day.3.hours.ago
)। इन टाइम क्वालिफायर के बहुवचन रूप भी स्वीकार किए जाते हैं (उदाहरण के लिए 5.minutes.ago
). उनका उपयोग git reflog
कमांड के साथ निम्नानुसार किया जा सकता है:
git reflog show develop@{3.days.ago}
git reflog
कुछ अतिरिक्त तर्कों को स्वीकार करता है जिन्हें इस प्रकार उप-आदेश के रूप में माना जाता है, जैसे कि show
, expire
और delete
। आइए इन उप-आदेशों पर विस्तार से चर्चा करें।
जैसा कि पहले चर्चा की गई थी, show
को डिफ़ॉल्ट रूप से परोक्ष रूप से पारित किया जाता है। निष्पादित git reflog show
पारित तर्कों के लिए लॉग प्रदर्शित करेगा।
उदाहरण के लिए:
git reflog develop@{0}
वैसा ही है जैसा कि
git reflog show develop@{0}
इसके अलावा, git reflog show
git log -g --abbrev-commit --pretty=oneline
लिए एक उपनाम है।
expire
सब-कमांड पुरानी या अगम्य रीफ्लॉग प्रविष्टियों को साफ करने में मदद करता है।
expire
सब-कमांड में डेटा हानि होने की संभावना होती है।
हालाँकि, यह उप-आदेश आमतौर पर अंतिम उपयोगकर्ताओं द्वारा नहीं बल्कि आंतरिक रूप से git द्वारा उपयोग किया जाता है।
एक "ड्राई रन" को -n
या --dry-run
विकल्प को git reflog expire
आउटपुट में पास करके किया जा सकता है, जिसमें reflog प्रविष्टियों को छंटनी के लिए चिह्नित किया जाता है, जैसे कि उन्हें वास्तव में काटा नहीं जाएगा। यह समाप्त हो चुकी रीफ्लॉग प्रविष्टियों को साफ करते समय सुरक्षा जाल के रूप में मदद कर सकता है।
इसके अलावा, समाप्ति समय को कमांड लाइन तर्क --expire=time
से git reflog expire
Expire पास करके या gc.reflogExpire
के git कॉन्फ़िगरेशन नाम को सेट करके निर्दिष्ट किया जा सकता है।
उपकमांड हटाएं, जैसा कि इसके नाम का तात्पर्य है, पारित रीफ्लॉग प्रविष्टि को हटा देता है। समाप्ति की तरह हटाएं, डेटा हानि का कारण बनने की क्षमता है और अंतिम उपयोगकर्ताओं द्वारा अक्सर इसका उपयोग नहीं किया जाता है।
git reflog
और git log
दो समान नाम वाले घटक हैं जो Git द्वारा प्रदान किए गए हैं जो हमें रिपॉजिटरी के प्रतिबद्ध इतिहास, लॉग और रीफ्लॉग में घुसने देते हैं। तथ्य यह है कि दो घटक अक्सर एक ही इतिहास प्रदर्शित करते हैं, खासकर जब कोई डेवलपर बिना किसी फ़ेच या पुल के कई स्थानीय प्रतिबद्धताओं को पूरा करता है, गिट रीफ्लॉग बनाम लॉग भ्रम के कारणों में से एक है।
हालांकि, ये अनिवार्य रूप से अलग हैं और अलग-अलग उपयोग के मामले हैं।
आइए अंतर्निहित अंतरों के साथ-साथ उपरोक्त दो आदेशों की समानता को भी समझते हैं।
गिट रीफ्लॉग और लॉग के बीच सबसे उल्लेखनीय अंतर यह है कि लॉग रिपोजिटरी के प्रतिबद्ध इतिहास का एक सार्वजनिक रिकॉर्ड है, जबकि रीफ्लॉग रेपो के स्थानीय कामों का एक निजी, कार्यक्षेत्र-विशिष्ट रिकॉर्ड है।
पुश, फ़ेच या पुल के बाद, गिट लॉग को गिट रिपॉजिटरी के हिस्से के रूप में दोहराया जाता है। दूसरी ओर, Git reflog, डुप्लिकेट किए गए रेपो में शामिल नहीं है। कंप्यूटर तक भौतिक पहुंच के बिना जहां स्थानीय भंडार रखा जाता है, एक डेवलपर रीफ्लॉग की जांच नहीं कर सकता है।
reflog .git\logs\refs\heads
में पाई जाने वाली एक फ़ाइल है जो एक विशिष्ट शाखा के लिए स्थानीय कमिट के इतिहास को ट्रैक करती है और किसी भी कमिट को बाहर करती है जिसे Git कचरा संग्रह प्रक्रियाओं द्वारा दूर किया जा सकता है। दूसरी ओर, गिट लॉग एक शाखा का ऐतिहासिक प्रतिबद्ध ट्रैवर्सल प्रदान करता है जो सबसे हालिया प्रतिबद्धता से शुरू होता है और शाखा के इतिहास में पहली प्रतिबद्धता के साथ समाप्त होता है।
Git reflog को विकास के दौरान सुरक्षा जाल के रूप में उपयोग किया जा सकता है क्योंकि यदि आप reflog की अवधारणा को सही ढंग से समझते हैं तो आप अपने रेपो से डेटा नहीं खो सकते हैं। आप रीफ्लॉग का उपयोग यह देखने के लिए कर सकते हैं कि आप पहले कहां थे और git reset --hard
उस रेफरी पर वापस जाने के लिए अपनी पूर्व स्थिति को पुनर्स्थापित करने के लिए यदि आप अनजाने में एक पुरानी प्रतिबद्धता पर रीसेट करते हैं, गलत तरीके से रीबेस करते हैं, या कोई अन्य ऑपरेशन करते हैं जो स्पष्ट रूप से "हटा देता है" करता है।
याद रखें कि refs केवल कमिटमेंट ही नहीं, बल्कि कमिटमेंट के पूरे इतिहास को संदर्भित करता है।
इस लेख में, हमने git reflog
के विस्तारित कॉन्फ़िगरेशन विकल्पों, सामान्य उपयोग-मामलों और git reflog
के नुकसान पर चर्चा की।
संक्षेप में, गिट एक रीफ्लॉग रखता है, जो आपके काम के दौरान पृष्ठभूमि में पिछले कुछ महीनों (90 दिनों) के लिए आपके HEAD
और शाखा संदर्भों का एक लॉग है। जब भी आपकी शाखा टिप को किसी भी कारण से संशोधित किया जाता है तो Git इस अस्थायी इतिहास में जानकारी सहेजता है।
रीफ्लॉग कमांड का उपयोग उन प्रविष्टियों को हटाने या समाप्त करने के लिए भी किया जा सकता है जो रीफ्लॉग से बहुत पुरानी हैं। उप-आदेश की expire
पर पुरानी रीफ्लॉग प्रविष्टियों को हटाने के लिए उपयोग किया जाता है और delete
गए उप-आदेश का उपयोग रीफ्लॉग से हटाने के लिए विशिष्ट प्रविष्टि को हटाने और निर्दिष्ट करने के लिए किया जाता है।